Anycast is a network addressing and routing methodology for routing packets from a sender to the closest of several potential recipients that are each identified with the same address. Anycast is built upon the Border Gateway Protocol (BGP). BGP advertisements announce that the same address is available at different topological locations throughout a network (i.e., Internet). Routers receiving the advertisements continually cull their routing tables to identify the shortest path to one such Anycast destination.
Anycast lends itself for use with a distributed platform. A distributed platform operates a plurality of geographically distributed points-of-presence (PoPs) for the purpose of serving content or providing services from each of those PoPs to users that are closest to the PoPs. Each PoP typically includes at least two collocated servers. The multiple servers of a given PoP host the same or different content and/or perform the same or different services. This ensures that the PoP has adequate resources for serving the content or for providing the various services while also ensuring redundancy and balanced load distribution across the PoP.
By using Anycast in combination with such a distributed platform, user requests for content or services can be routed to the distributed platform PoP that is closest to the requesting user. In so doing, the Anycast identified PoP can deliver the content or services in an optimal manner in part because of the proximity to the user. For example, a user experiences less latency and packet loss when receiving content from a proximate Anycast identified PoP than other more distant servers or PoPs. A content delivery network (CDN) is an example of a distributed platform that benefits from the routing efficiencies of Anycast.
However, some legacy routing and control mechanisms of underlying networking protocols were never designed to work with such Anycast reliant distributed platforms. As a result, aberrant behavior may occur in these Anycast reliant distributed platforms, but not in traditional Unicast, Broadcast, or Multicast reliant distributed platforms.
FIG. 1 provides an exemplary case of legacy control messaging producing aberrant behavior in an Anycast reliant distributed platform. FIG. 1 presents a message exchange between a client 110 and an Anycast identified PoP 120 of the distributed platform, wherein the aberrant behavior results from a control message that is issued by an intermediary node 115 in the path connecting the client 110 to the PoP 120. The PoP 120 includes a core router 125, at least two directors 130 and 135 and a set of two servers 140 and 145, though the same aberrant behavior would be observed if the PoP 120 was horizontally or vertically scaled.
The message exchange commences with the client 110 submitting (at 150) a request for content to an Anycast address of the distributed platform. Anycast routing delivers the request to the PoP 120 and more specifically, to the core router 125. The core router 125 performs a simple hash of the source and destination addresses specified in the request header to select director 130 to process the request. The core router 125 then forwards (at 155) the request to the selected director 130.
The director 130 is tasked with selecting (at 160) a server from the set of servers 140 and 145 to respond to the user request. The director 130 first performs a session table lookup to determine if a prior session is established for the request and if a server has already been selected to handle the session. In this case, no prior session exists and the director 130 selects server 140 based on a hash of the name and/or path of the content specified in the request and/or addressing information from the request header. The director 125 creates a session table entry such that future inbound packets from the client 110 that are associated with the session are properly routed to the correct server 140. The session is identified by a source and destination address combination, wherein the term address refers to any one or more of a Media Access Control (MAC) address, Internet Protocol (IP) address, and application or transport layer protocol port number. In this example, the session table entry identifies the current session with a source IP address and source port pair and a destination IP address and destination port pair. After creating the session, the director forwards (at 165) the request to the selected server 140.
The server 140 processes the request and begins serving (at 170) the requested content to the client 110 in response. However, the intermediary node 115 in the connection between the client 110 and the server 140 submits (at 175) a control message back to the Anycast address specified by the original request. Control messages can be used for a variety of reasons. For the current example, the control message indicates that the intermediary node 115 cannot support the manner in which the server 140 sends the content. One such control message indicates that the intermediary node 115 does not support packets of the size submitted by the server 140 and that the server 140 should retransmit the packets with a smaller size. Such a control message can be an Internet Control Message Protocol (ICMP) message indicating that the packet(s) exceeds the maximum transmit unit (MTU) supported by the intermediary node 115. It is significant to note that the source address of the control message is the address of the intermediary node 115 and not the address of the client 110. Also, in some instances, the destination address of the control message may identify the Anycast address and not the unique IP address for the actual server 140 within the PoP 120 that transmits the offending packets that cause the intermediary node 115 to issue the control messages.
Upon receiving the control message, the core router 125 may select (at 180) an incorrect director that has no knowledge of the client's 110 active session (i.e., director 135) as the selection is based on a hash of the intermediary node 115 address that is provided in the control message header rather than the client 110 address. If the control message is passed from the core router 125 to director 135 (i.e., the incorrect director), the director 135 will be unable to identify the server 140 or the session to which the control message relates. Specifically, the session table maintained by director 135 will not have any entry for the address combination in the control message header, and will also lack any entry for the address combination used to identify the session created by director 130. Even if the core router 125 forwards the control message to the correct director 130, the director 130 will still be unable to identify the server 140 or the session to which the control message relates as the director's session table will not have any entries for the addressing that is provided in the control message header. Consequently, there is no guarantee that the control message will arrive at the appropriate server 140 that is handling the session. Until the control message arrives at the server 140, the server 140 continues to send the offending packets and the intermediary node 115 continues to block or drop those packets, thus preventing the client 110 from receiving the requested content.
The above depicts one scenario where aberrant behavior results from legacy control mechanisms in an Anycast reliant distributed platform. Similar aberrant behavior is observed in PoPs, clusters, or service regions of Anycast reliant distributed platforms having different architectures. Also, the aberrant behavior is observed when different control messages besides the exemplary case described above are issued by intermediary nodes. Accordingly, there is a need to resolve these and other aberrant behavior occurring within Anycast reliant distributed platforms. More specifically, there is a need to adapt legacy control mechanisms and control messages for Anycast reliant distributed platforms.